SQL Server 2008 Reporting Services : Management and Security

Securing Reports

As we’ve seen in previous examples, SSRS has a built-in, role-based security system. All operations done on the server are subject to permissions. Access to SSRS is controlled through security roles and role assignments.

A security role is a collection of permissions—for example, the permission to create reports in a folder, the permission to view a certain report or a folder.

A role assignment is a set of permissions represented by the role given to a principal on a certain report or folder in the Report Server catalog. For example, the permissions on a folder called Data Sources contain the local administrators group with all permissions contained in the Content Manager role.

Permissions on folders are inherited to all items present in that folder, unless security inheritance is intentionally broken and the item is given its own permissions.

Built-in Roles and Permissions

SSRS comes with a set of built-in roles. Each role is a collection of permissions, normally used in tandem to enable a functional scenario. Following are some of the built-in roles:

• Browser— This role is a collection of read-only permissions that is useful for navigating the Reporting Services namespace and viewing reports and resources.

• Content Manager— This role is similar to an administrator on the part of the Report Server where it is granted. A person who has the Content Manager role can view and change any reports, folders, data sources, and resources and can read and set security settings in the folders where he or she has that permission.

• Publisher— This role is useful for report authors who need to create and change reports, folders, and data sources in a specified folder.

• Report Builder— This role can be used for granting permissions needed for editing Report Builder reports.

• My Reports— This security role is normally given to each user in his or her own My Reports folder. It gives each user of the Report Server his or her own place to publish documents on the server.

The security roles system is fully customizable. You can change or even delete existing roles, and you can also create new ones. To view and modify these roles, you use SSMS. Connect the Object Explorer to your SSRS instance and then navigate to the Security, Roles node. View the Properties page for any role definition to manage its permissions.

Local administrators on the Report Server machine are granted Content Manager permissions at the root of the SSRS catalog, and no one else has any permissions. To make the Report Server accessible to users, you need to explicitly grant permissions on the folders you want to make available to them.

System Roles and System Permissions

So far we have talked about permissions only on items in the Report Server namespace: reports, folders, and data sources. The Report Server also contains a set of server-wide roles and permissions. They are called system roles, and you can access them using SSMS as described previously.

As mentioned earlier, system roles are collections of permissions, such as View Shared Schedules or Execute Report Definitions. These permissions are not specific to a certain folder or part of the namespace but are global to the entire Report Server installation. A site permission is a collection of these roles assigned to users or groups. Out of the box, local administrators on the Report Server box are, by default, given the permissions contained in the System Administrator role.

To open your system to users, you add Windows users and groups to the site security. As with normal roles, you can change or delete the built-in system roles, or you can create other system roles.

Subscriptions

An important advantage to having reports available on a Report Server is that you can use its subscription features to push reports to users.

You can create subscriptions using Report Manager. Start by publishing a report to the catalog. Start Report Manager, click the Details View link, hover over a report of your choice, and then click Subscribe.

The first step in the Subscription dialog is to choose a delivery mode. There are three built-in delivery methods: email, file share, and null. The null delivery, as its name suggests, doesn’t deliver anywhere; however, you can use it as a way to periodically load reports into the Report Server cache. For details, see the section “Report Execution Options,” later in this chapter.

For this example, choose Windows File Share as the delivery method and fill in the file name, path, render format, server credentials, and overwrite options. The next step is to pick a schedule. You can set a schedule just for this report subscription, or you can use a shared schedule for several subscriptions. Five recurrence patterns are available for subscriptions: Hourly, Daily, Weekly, Monthly, and Once.

If your report has parameters, you also need to decide which parameter values to supply when the report is executed as part of the subscription.

One restriction in creating subscriptions is that report data sources must rely on stored credentials, whether Windows or database credentials. Integrated security and prompted credentials are not compatible with subscriptions because the actual user isn’t around at runtime.

Data-Driven Subscriptions

Another way to customize report delivery is through data-driven subscriptions. A dynamic or data-driven subscription is very useful for delivering parameterized reports to a number of recipients whose email addresses are stored in a database, for instance. Unlike with a regular subscription, the recipient’s settings—such as the To or CC address, the title of the email, and the parameters of the report being run—can all be based on a SQL Server query. For example, using the AdventureWorks2008R2 sample database, let’s say you want to send quarterly human resources information reports to all managers at the company.

Suppose you have created a Human Resources report that takes a parameter, the login ID of an employee. If that employee is a manager, the report displays a list of all employees reporting to him or her, together with the person’s title, the base pay rate, vacation hours, and sick leave hours.

You start the Data-Driven Subscription Creation Wizard using Report Manager by clicking the New Data-driven Subscription button on the Subscription tab for your Human Resources report. Type a name (such as Send quarterly HR reports to managers) and select the email delivery extension for the subscription. Then click Next.

On the data source page, use the shared AdventureWorks2008R2 data source you created earlier. Enter the query shown in Listing 1, which selects email addresses and login IDs for all managers.

Listing 1. T-SQL for a Data-Driven Report Subscription

SELECT DISTINCT
    pe.EmailAddress,
    e2.LoginID
FROM HumanResources.Employee e
JOIN HumanResources.Employee e2
ON e2.OrganizationNode = e.OrganizationNode.GetAncestor(1)
JOIN Person.Person p
ON p.BusinessEntityID = e2.BusinessEntityID
JOIN Person.EmailAddress pe
ON pe.BusinessEntityID = e2.BusinessEntityID
ORDER BY pe.EmailAddress

Next, bind EmailAddress to the To field in the email and LoginID to the LoginID parameter of the Human Resources report. The last step is to choose a schedule for this subscription.

Subscription and Delivery Architecture

Let’s look at what happens under the covers when a subscription is created. The metadata for the subscription is validated and stored in the Report Server catalog database. A SQL Agent job is created, and the schedule specified in the subscription is saved in the SQL Agent job.

When the time comes, the SQL Agent job fires, inserting a so-called “event” row in the Report Server catalog. The Report Server matches the event with the information about the subscribers and sends notifications to the subscribers. The notifications are processed in the Report Server Windows service; the report is run and delivered to its target.

This architecture allows SSRS to scale very well with the number of subscribers and events. Because the events are recorded in the catalog database, it also allows for a scale-out configuration, so you can have a number of services process notifications in parallel, thus achieving greater scalability.

Report Execution Options

Another very useful feature of SSRS is the capability to cache report content and dataset data, to display data as of a certain date, to display historical snapshots of those data, to refresh those snapshots, and to do so on a scheduled basis. The following sections describe these capabilities.

Live Reports and Sessions

By default, when a report is deployed on the server, it is configured to be run live, or on demand. Every time a user clicks a report link in Report Manager, the report queries are executed. The report is processed, filters are applied, sorting is performed, and expressions are evaluated. Finally, the report is rendered to the desired format and returned to the user. The binary result of report execution is stored in a format-independent fashion in the Report Server’s temporary database (ReportServerTempDB). This result is known as a session snapshot. When you page through a report or export it to a different format, the session snapshot is used to perform these operations; this way, report queries do not have to be rerun.

A session snapshot is tied to a specific user, is typically associated with a browser session, and is generally short lived (on the order of minutes).

Cached Reports

Let’s assume (safely) that report queries take a relatively long time to run and the data to be displayed doesn’t change very often. In that case, you can set execution options to cache the report. To do so, in Report Manager, view any report’s properties (hover over it and select Manage); then click the Processing Options tab at the left of the page. Select one of the caching option radio buttons (other than the default Do Not Cache Temporary Copies of This Report). When the first user accesses the report, it is executed (as described earlier), but the resulting snapshot will, from that point on, be saved and then shared across user sessions. When a second user clicks the report link, instead of the report running again, the user gets the snapshot that was generated when the first user ran it.

There are two ways to remove a snapshot from the cache:

• After a certain number of minutes of inactivity— This is a “sliding” expiration, meaning that as long as users navigate to the report, it is kept in the cache. If no one has requested the report for more than the specified number of minutes, the cache is expired, and the next report request causes a live execution, which starts another cache session, and so on.

• On a schedule— This is useful if the data is not valid after a certain date (for example, if sales information changes every two weeks), and you don’t want any cached report to show data older than this date.

Execution Snapshots

Snapshots are an extremely useful bit of functionality: they enable SSRS to fetch a report’s data, prerender the report ahead of its actual execution time, and then save that intermediate format for fast retrieval. If you configure your report to use snapshots, when the time comes for a user to run it, it will render very quickly because the data has already been culled from the report’s data sources and stored in ReportServerTempDB. The only downside is staleness of data, but you can adjust the snapshot creation interval to your customer’s liking.

If you don’t want your users to run reports against live data (for example, if the queries are prohibitively expensive or they make sense only for end-of-month sales and the report should be run only on the first day of each month for the data to be relevant), you can set the report settings to Execution Snapshot. The Report Server then runs the report on this schedule. Your users always get the data from this execution snapshot.

The main difference between execution snapshots and cached reports is that cached reports can run live if the cached data has expired; execution snapshots, on the other hand, are guaranteed to run only on the specified schedule.

Historical Snapshots

Historical snapshots are useful if you want to keep historical data for your reports. Say that you want to track all monthly sales reports from month to month. You can configure this on the Snapshot Options tab on the Report Properties window. You simply set the option Use the Following Schedule to Add Snapshots to Report History and then create a new or use an existing shared schedule.

To see historical snapshots, go to Report Manager, click the report, and then click the Report History tab. Notice the list of historical snapshots taken from the selected report (you can also create a new snapshot on demand on this screen). When you click a report on the list, you see the actual report data.

Cache Refresh Plans

Cache refresh plans (CRPs) are a new feature in SSRS 2008 R2. As the name implies, a CRP is a plan that controls when cached shared dataset or report data is to be automatically refreshed. To create a CRP, view any report or shared dataset in Report Manager; then hover it and click Manage. On the left, click Cache Refresh Options and then click the New Cache Refresh Plan button at the top of the page (if you already have a CRP, you can create a new CRP using the existing one as a baseline). You may get a confirmation dialog asking if it’s okay to enable caching for the selected item. Answer in the affirmative. On the ensuing screen, enter a description for your new plan, create a new item-specific schedule, or use an existing shared schedule; then click OK (ensure that the SQL Agent service is running before doing so). If you are working with a shared dataset, your steps are complete. If you are working with a report that has one or more parameters, there is one more step to consider.

When caching a parameterized report, SSRS needs values supplied for all report parameters (at least, for those which do not except an empty value). A discrete set of cached report data is created for every unique combination of input parameter values you specify. Any errors in input render your CRP inactive.

User-Specific Data Limitations

Cached reports, execution snapshots, and history snapshots all have something in common: they each allow sharing of report data among users. This means that a given SSRS instance does not let you use these features with reports that contain user-specific data. Per-user references in the report include the usage of User!UserID in the report definition, the use of integrated security in the report data sources, and the Impersonate After Connection Is Made option for SQL Server data sources.